Security and compliance of software systems may depend on the appropriate configuration of many different information technology (IT) components. For example, a software system lifecycle typically starts with a planning and design phase, where the architecture of the software system is planned. The deployment phase implements the design concept, and includes the installation of all relevant software components (e.g., web applications, application servers, databases, etc.) as well as the initial configuration of these components. The security-relevant parts of the configuration settings are initially intended to execute the application in a secure and compliant manner. However, at the operations phase (in which the application is productively utilized), the configuration settings may be changed, which may result in a risk that a security-relevant setting is altered in an unintended way. This risk may occur for several reasons: people performing configuration changes are typically different from those who planned and deployed an application; the original motivation to configure a component may not have been documented; and/or or the security implications of a configuration setting may not be evident.
However, to prevent insecure configuration settings, security administrators or auditors may check the configuration to see whether the configuration settings still meet expectations. There are several conventional approaches that control the change, validation, and audit of configuration settings of the software system. In one example, an Information Technology Infrastructure Library (ITIL) change management process may describe the way how configuration changes in software systems shall be requested, approved, and deployed. In another example, a system management tool may automatically validate the configuration settings at regular intervals and generate an alarm if any incorrect, potentially harmful setting is discovered. However, these conventional approaches are not linked to the actual application runtime. As such, they do not prevent the execution of an application, which has been configured incorrectly.
For example, the ITIL change management process may coordinate the interaction of various stakeholders that altogether aim to prevent inappropriate settings. If, for instance, a change is made without going through the ITIL change management process, or if the change request reviewer does not understand the security impact of a configuration change, the modification can be implemented even though an application is configured in an insecure or non-compliant manner. The system management tool, on the other hand, only aims at discovering dangerous configuration settings at regular intervals, which qualifies them as merely detection controls. However, such conventional approaches cannot prevent an application from being executed during runtime in the event that the application is configured incorrectly. In other words, the conventional approaches merely detect an incorrect configuration setting, but do not employ preventive measures that avoid applications from be executed in an insecure or non-compliant manner.